home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Freaks Macintosh Archive
/
Freaks Macintosh Archive.bin
/
Freaks Macintosh Archives
/
Ham⁄GPS
/
IP Folder
/
HAMradio TCP⁄IP
/
Docs
/
is_es Command Documentation
< prev
next >
Wrap
Text File
|
1993-01-03
|
4KB
|
78 lines
Intermediate system to End-system (IS-ES): Functional Description
Let's assume that we have a dynamically routed network together and two
stations are trying to communicate across a chain of inter-connected IS.
Ignore for a moment how the first ES finds an IS to forward packets to
the destination; lets consider how the last IS in the route sets up the
final hop to the destination ES and enables the route back to the
source.
For ease of description, consider the simple case of two ES trying to
communicate through a single IS (extending to multiple IS works just the
same way, :-) derivation is left to the reader.
Three nodes A,B,and C. A uses B as a gateway to C.
In the pre-routing case, the following message exchange would occur if A
attempted to communicate with C.
A B C
ARP request, target B->
<- ARP reply from B-A
IP [A]=>[C] via B->
ARP request, target C->
<- ARP reply from C-B
IP [A]=>[C] ->
<- ARP request, target A
IF no path exists between A and C this is the end of the world unless C
had manually added a route saying that traffic from C to A goes via B.
The first phase of routing answers this problem:-
When B gets an IP packet to forward, it notes if it is being used as a
router (IS) and determines whether the next hop is the last hop in the
route. This is done in iproute() after route resolution by checking
ip.dest against gateway. If the two are the same, this is the last hop.
We're a gateway if ip.src is not our own IP address.
If these conditions are met, ip_route() calls a routine to enable IS-ES
routing from the source IP address to the destination.
The packet is forwarded normally but when C issues an ARP request to
resolve where A is, B will respond on behalf on A. This can be
considered a limited form of proxy ARP. B will only respond to an ARP
request, target A, from C and only C.
C will now pass IP packets to B which will get forwarded to A in the
normal way. We now have a route from A to C and have established a way
for C to get back to A.
B has a table of which IP addresses it should respond to ARP requests
and to whom it should respond. Table entries are aged and ultimately
dropped on a time period similar to normal ARP entries.
This capability is implemented via the is_es command. This function was
first developed by Stu Phillips, N6TTO for NOS and was ported with his
permission to NET/Mac. I've implemented the above and here are the
results of initial testing:-
1. It works just fine subject to *one* problem. Once A and C are in
communication and the channel gets congested, TCP connections running
over the route begin to back-off as normal. If the channel gets
really congested, it is possible that the back-off period gets longer
than the life of the IS-ES routing table entry at B and longer than ARP
table entry for A at C. So when the TCP retry timer completes, C will
ARP for A but B will no longer respond. The connection is now hung just
as if A and C were in direct communication and A simply went away (eg:
power'd off). The solution to this is full routing; in the meantime
the function still serves a useful purpose in enabling communication
between nodes.
2. Round-trip times are clearly going to be longer than for direct node
to node connections. This exacerbates the TCP back-off problem
described above.